Skip Headers

Oracle® Data Guard Broker 10g Release 2 (10.2) Part Number B14230-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 9 Database Properties

Database properties help you to view and control the behavior of databases, redo transport services, and log apply services in a broker configuration. This chapter provides the following sections about the monitorable and configurable properties:

- Section 9.1, "Monitorable (Read-Only) Database Properties"

- Section 9.2, "Configurable Database Properties"

The scope of some properties is said to be database-wide. If the database (primary or standby) is a RAC database consisting of multiple instances, the value of such a property applies uniformly across all of the instances sharing that database. The scope of other properties is said to be instance-specific. Such a property exists for all instances of the RAC database, but its value may differ from one specific instance to another.

Note: This chapter presents properties primarily from the point of view of the Data Guard command-line interface (DGMGRL). Using DGMGRL, the properties described in this chapter may be viewed or modified using discrete DGMGRL commands. Enterprise Manager explicitly presents some of these properties on the Edit Properties page. Information from other properties may be implicitly incorporated into other Web pages displayed by Enterprise Manager. Each property's description in this chapter indicates how Enterprise Manager presents that property.

## 9.1 Monitorable (Read-Only) Database Properties

Monitorable properties allow you to view information related to the database or the instance, but you cannot change the values of these properties. You can view all of the monitorable properties using the DGMGRL `SHOW` commands.

Note: Information for monitorable properties can be seen only when broker management of the database is enabled and the database is in an online state. Enterprise Manager displays the information obtained from these properties on the Property page.

If the database is a RAC database, the output values of some properties may also show instance-specific information. For example if the primary database is a RAC database, `LogXptStatus` may show `Instance1` transmitting redo data to `Standby2` has an error and `Instance2` transmitting redo data to `Standby4` has an error.

The following sections describe the database monitorable properties:

- InconsistentLogXptProps (Inconsistent Redo Transport Properties)

- InconsistentProperties (Inconsistent Database Properties)

- LogXptStatus (Redo Transport Status)

- LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)

- LsbyParameters (Logical Standby Parameters)

- LsbySkipTable (Logical Standby Skip Table)

- LsbySkipTxnTable (SQL Apply Skip Transaction Table)

- RecvQEntries (Receive Queue Entries)

- SendQEntries (Send Queue Entries)

- StatusReport (Status Report)

- TopWaitEvents

### 9.1.1 InconsistentLogXptProps (Inconsistent Redo Transport Properties)

The `InconsistentLogXptProps` property returns a table that shows all properties related to redo transport services whose values are inconsistent between the broker configuration file and the runtime value in the database.

The properties reported in this table can be either database-specific properties or instance-specific properties. A database-specific property only ensures that there is one value in the broker's configuration file for all instances sharing the database, but the runtime values among the instances can be different. This means that a database-specific property may be inconsistent only on some instances.

This property pertains to the primary database. The table contains the following columns:

- `INSTANCE_NAME`

  The value matching the SID for the instance.

- `STANDBY_NAME`

  The database unique name (`DB_UNIQUE_NAME`) of the standby database to which this redo transport services property pertains.

- `PROPERTY_NAME`

  The name of the redo transport services property with an inconsistent value.

- `MEMORY_VALUE`

  The runtime value being used in the database.

- `BROKER_VALUE`

  The value of the redo transport services property saved in the broker configuration file.

### 9.1.2 InconsistentProperties (Inconsistent Database Properties)

The `InconsistentProperties` property returns a table that shows all database properties whose values contained in the broker configuration file are inconsistent with the values in the corresponding server parameter file or the runtime values in the database.

The properties reported in this table can be either database-specific properties or instance-specific properties. A database-specific property only ensures that there is one value in the broker's configuration file for all instances sharing the database, but the runtime memory values or SPFILE values among the instances can be different. This means that a database-specific property may be inconsistent only on some instances.

Each individual database has this property. The table contains the following columns:

- `INSTANCE_NAME`

  The value matching the SID for the instance.

- `PROPERTY_NAME`

  The name of the database property with the inconsistent value.

- `MEMORY_VALUE`

  The corresponding runtime value being used in the database.

- `SPFILE_VALUE`

  The corresponding value saved in the server parameter file (SPFILE).

- `BROKER_VALUE`

  The value of the database property saved in the broker configuration file.

### 9.1.3 LogXptStatus (Redo Transport Status)

The `LogXptStatus` property returns a table that contains the error status of redo transport services for each of the enabled standby databases. This property pertains to the primary database.

The table contains the following columns:

- `PRIMARY_INSTANCE_NAME`

  The value matching the SID for the instance on the primary database.

- `STANDBY_DATABASE_NAME`

  The database unique name (`DB_UNIQUE_NAME`) of the standby database.

- `ERROR`

  The text of the redo transport error. If there is no error, the field is empty.

Each entry in the table indicates the status of redo transport services on one primary instance to one standby database.

The format of the error status is as follows:

    "standby1_sitename=error_status, standby2_sitename=error_status,..."

The error status can be an empty string, which indicates there is no error.

In the following example, the `STATUS` from `DR_Sales` is empty because there is no error for the `DR_Sales` destination. The `South_Report` destination returned the `ORA-01034` message.

    DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus' ;
    LOG TRANSPORT STATUS
    PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME               STATUS
                 sales1            DR_Sales
                 sales1        South_Report      ORA-01034: ORACLE not available

### 9.1.4 LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)

The `LsbyFailedTxnInfo` property identifies a failed transaction that caused log apply services to stop. This property contains a string with the following values from the `DBA_LOGSTDBY_EVENTS` view:

- `XIDUSN`: Transaction ID undo segment number

- `XIDSLT`: Transaction ID slot number

- `XIDSQN`: Transaction ID sequence number

- `STATUS_CODE`: Status (or Oracle error code) belonging to the `STATUS` message

- `STATUS`: Description of the current activity of the process or the reason why log apply services stopped

The transaction IDs and status information are separated by a string of number signs (###). This property pertains to a logical standby database.

### 9.1.5 LsbyParameters (Logical Standby Parameters)

The `LsbyParameters` property contains a string that identifies the value of `MAX_SGA` (maximum system global area) and `MAX_SERVERS` (maximum number of parallel query servers) specifically reserved for log apply services. These values are separated by a string of number signs (###) in the `LsbyParameters` property.

This property pertains to a logical standby database.

### 9.1.6 LsbySkipTable (Logical Standby Skip Table)

The `LsbySkipTable` property lists the SQL Apply skip specifications. These skip specifications specify filters for SQL Apply to skip applying a certain class of online redo log files on the logical standby database. This property returns a table with the following columns from the `DBA_LOGSTDBY_SKIP` view:

- `ERROR`

  Indicates if the statement should be skipped (`Y`) or if errors should be returned for the statement (`N`)

- `STATEMENT_OPT`

  Indicates the type of statement that should be skipped

- `SCHEMA`

  The schema name for which this skip option should be used

- `NAME`

  Name of the object for which this skip option should be used

- `PROCEDURE`

  Name of the stored procedure to execute when processing the skip option

### 9.1.7 LsbySkipTxnTable (SQL Apply Skip Transaction Table)

The `LsbySkipTxnTable` lists the skip settings chosen. This property returns a table with following columns:

- `XIDUSN`: Transaction ID undo segment number

- `XIDSLT`: Transaction ID slot number

- `XIDSQN`: Transaction ID sequence number

- `ACTIVE`: Description of the current activity of the process or the reason why SQL Apply stopped

This property pertains to SQL Apply.

### 9.1.8 RecvQEntries (Receive Queue Entries)

The `RecvQEntries` property returns a table indicating all log files that were received by the standby database but have not yet been applied. If no rows are returned, it implies all log files received have been applied. This property pertains to a standby database.

The table contains the following columns in the order shown:

- `STATUS`

  The `STATUS` column is set to one of the following values for a log file on a logical standby database:

  - `NOT_APPLIED`: No redo records in this log file have been applied.

  - `PARTIALLY_APPLIED`: Some of the redo records in this log file have been applied while others have not.

  - `COMMITTED_TRANSACTIONS_APPLIED`: This status value only applies to a logical standby database. All redo records belonging to the committed transactions have been applied. Redo records belonging to uncommitted transactions have not been read by LogMiner and may still be needed when the transactions are committed in the future. Therefore, it is not safe yet to discard this online redo log file.

- `RESETLOGS_ID`

  Resetlogs identifier associated with the archived redo log file

- `THREAD`

  The redo thread number

- `LOG_SEQ`

  The online redo log file sequence number

- `TIME_GENERATED`

  The first time when the online redo log file was written to the primary database

- `TIME_COMPLETED`

  The next time when the log file was archived on the primary database (corresponds to the `NEXT_CHANGE#` column)

- `FIRST_CHANGE#`

  First change number in the archived redo log file

- `NEXT_CHANGE#`

  First change in the next log file

- `SIZE (KBs)`

  The `SIZE` of the online redo log file in kilobytes

For example:

    DGMGRL> SHOW DATABASE 'DR_Sales' 'RecvQEntries' ;
                  STATUS     RESETLOGS_ID           THREAD
    LOG_SEQ          TIME_GENERATED       TIME_COMPLETED    FIRST_CHANGE#
    NEXT_CHANGE#        SIZE (KBs)
             NOT_APPLIED        497198843                1                    5
    06/20/2003 14:55:38  06/20/2003 16:31:26           202138
    210718             7364
             NOT_APPLIED        497198843                1                    6
    06/20/2003 16:31:26  06/20/2003 16:31:39           210718
    210753               13
             NOT_APPLIED        497198843                1                    7
    06/20/2003 16:31:39  06/20/2003 16:31:54           210753
    210758                1
             NOT_APPLIED        497198843                1                    8
    06/20/2003 16:31:54  06/20/2003 16:31:59           210758
    210789               11

Note: Enterprise Manager displays this information on the Log File Details page.

### 9.1.9 SendQEntries (Send Queue Entries)

The `SendQEntries` property returns a table that shows all log files on the primary database that were not successfully archived to one or more standby databases. This property pertains to the primary database.

The table contains the following columns:

- `STANDBY_NAME`

  The value can be empty or it can contain the database unique name (`DB_UNIQUE_NAME`) of the standby database. If empty, the `STATUS` column will contain a value of `CURRENT` or `NOT_ARCHIVED`.

- `STATUS`

  The `STATUS` column is set to one of the following values:

  - `CURRENT`: A log file to which online redo is currently being written.

  - `NOT_ARCHIVED`: A completed online redo log file that has not been archived locally.

  - `ARCHIVED`: A completed log file that has been archived locally but has not been transmitted to the standby database specified in the `STANDBY_NAME` column.

  The table contains exactly one row with the value of `STATUS=CURRENT`. There can be multiple rows with the value `STATUS=ARCHIVED` or `STATUS=NOT_ARCHIVED`.

- `RESETLOGS_ID`

  Resetlogs identifier associated with the archived redo log file

- `THREAD`

  The redo thread number.

- `LOG_SEQ`

  The log sequence number. Multiple rows may have the same `LOG_SEQ` value (for different `STANDBY_NAME` values).

- `TIME_GENERATED`

  The first time when the online redo log file was written to the primary database.

- `TIME_COMPLETED`

  The next time when the log file was archived on the primary database (corresponds to the `NEXT_CHANGE#` column).

- `FIRST_CHANGE#`

  First change number in the archived redo log file.

- `NEXT_CHANGE#`

  First change in the next log file.

- `SIZE (KBs)`

  The `SIZE` of the online redo log file in kilobytes.

For example, the following shows output from a `SHOW DATABASE` command:

    DGMGRL> SHOW DATABASE 'North_Sales' 'SendQEntries' ;
    PRIMARY_SEND_QUEUE
            STANDBY_NAME       STATUS     RESETLOGS_ID
    THREAD              LOG_SEQ       TIME_GENERATED       TIME_COMPLETED
    FIRST_CHANGE#     NEXT_CHANGE#       SIZE (KBs)
           sales1     ARCHIVED        497198843
    1                    9  06/20/2003 16:31:59  06/20/2003 16:39:57
    210789           211411              186
           sales1     ARCHIVED        497198843
    1                   10  06/20/2003 16:39:57  06/20/2003 16:40:01
    211411           211415                1
           sales1     ARCHIVED        497198843
    1                   11  06/20/2003 16:40:01  06/20/2003 16:40:07
    211415           211418                1
                              CURRENT        497198843
    1                   12  06/20/2003 16:40:07
    211418                                 1

Note: Enterprise Manager displays this information on the Log File Details page.

### 9.1.10 StatusReport (Status Report)

The `StatusReport` property returns a table that provides a list of errors or warnings about the status of the database. In a RAC database environment, it also includes the status of all running instances. Each individual database has this property. The table contains the following columns in the order shown:

- `INSTANCE_NAME`

  The value matching the SID for the instance.

- `ERROR_TEXT`

  Formatted error text.

- `SEVERITY`

  The severity of the error message. The value is either `WARNING` or `ERROR`.

For example, the following shows output from a `SHOW DATABASE` command:

    DGMGRL> SHOW DATABASE 'North_Sales' 'StatusReport' ;
    STATUS REPORT
           INSTANCE_NAME   SEVERITY ERROR_TEXT
                 sales1      ERROR ORA-16737: the redo transport service for
    standby "DR_Sales" has an error
                       *      ERROR ORA-16745: unable to add DB_UNIQUE_NAME DR_Sales
    into The DG_CONFIG list because it is full

### 9.1.11 TopWaitEvents

Specifies the 5 events with the longest waiting time in the specified instance. The events and their waiting time are retrieved from `V$SYSTEM_EVENT`. Each instance in the configuration has this property. This property is an instance level monitorable property. The table contains the following columns in the order shown:

- Event

  The system wait event.

- Wait Time

  The total amount of time waited for this event in hundredths of a second.

See Also: See Oracle Database Reference for detailed explanations of all system wait events.

The following example shows output from a `SHOW INSTANCE` command:

    DGMGRL> SHOW INSTANCE sales1 'TopWaitEvents';
    TOP SYSTEM WAIT EVENTS
                   Event            Wait Time
       rdbms ipc message               671350
    SQL*Net message from client         62390
              pmon timer                47897
      Queue Monitor Wait                43016
     wakeup time manager                38508

## 9.2 Configurable Database Properties

Configurable database properties control the behavior of databases in a broker configuration. You can view and dynamically update the values of these properties using either DGMGRL or Enterprise Manager. However, some properties can only be updated through DGMGRL.

In most cases, the configurable database property is said to have database scope; meaning the value you set for the property applies uniformly to each instance of the database. However, in a few cases, the configurable database property is said to have instance scope; meaning, for a multiple-instance database environment, it is possible that the values of some particular properties may differ from one instance of the database to the next. Table 9-1 lists each configurable database property and indicates if the scope of the property is database-wide or instance-specific. If the Scope column contains:

- Database—The value of the property is database wide, not instance or configuration specific.

- Instance—The value of the property is instance specific, not database or configuration specific.

- Configuration—The value of the property is configuration wide, not instance or database specific.

Table 9-1 Configurable Properties

Configurable Property Name | Scope | Pertains To
--- | --- | ---
AlternateLocation | Instance | Redo transport services
ApplyInstanceTimeout | Database | Redo Apply and SQL Apply
ApplyParallel | Database | Redo Apply
ArchiveLagTarget | Database | Redo transport services
Binding | Database | Redo transport services
DbFileNameConvert | Database | Redo transport services
DelayMins | Database | Redo Apply and SQL Apply
Dependency | Database | Redo transport services
FastStartFailoverTarget | Database | Fast-start failover
FastStartFailoverThreshold | Configuration | Fast-start failover
HostName | Instance | Instance identification
InitialConnectIdentifier | Database | Broker communication
LocalListenerAddress | Instance | Broker communication
LogArchiveFormat | Instance | Redo transport services
LogArchiveMaxProcesses | Database | Redo transport services
LogArchiveMinSucceedDest | Database | Redo transport services
LogArchiveTrace | Instance | Diagnosis
LogFileNameConvert | Database | Redo transport services
LogShipping | Database | Redo transport services
LogXptMode | Database | Redo transport services
LsbyASkipCfgPr | Database | SQL Apply
LsbyASkipErrorCfgPr | Database | SQL Apply
LsbyASkipTxnCfgPr | Database | SQL Apply
LsbyDSkipCfgPr | Database | SQL Apply
LsbyDSkipErrorCfgPr | Database | SQL Apply
LsbyDSkipTxnCfgPr | Database | SQL Apply
LsbyMaxEventsRecorded | Database | SQL Apply
LsbyMaxSga | Instance | SQL Apply
LsbyMaxServers | Instance | SQL Apply
LsbyRecordAppliedDdl | Database | SQL Apply
LsbyRecordSkipDdl | Database | SQL Apply
LsbyRecordSkipErrors | Database | SQL Apply
LsbyTxnConsistency | Database | SQL Apply
MaxConnections | Database | Primary
MaxFailure | Database | Redo transport services
NetTimeout | Database | Redo transport services
PreferredApplyInstance | Database | Redo Apply and SQL Apply
ReopenSecs | Database | Redo transport services
SidName | Instance | Instance identification
StandbyArchiveLocation | Instance | Redo transport services
StandbyFileManagement | Database | Redo Apply and SQL Apply

See Also: Chapter 4 for more information about database property management

Note: When a broker configuration with its primary database is created and standby databases are added to the configuration, the broker imports existing settings from the databases to set many of the properties. If importing an existing setting fails, or if a property value is not imported, then the broker uses a broker default value. The default values and whether or not a property is imported is indicated within each property description.

### 9.2.1 AlternateLocation

Specifies an alternate disk location to store the archived redo log files in the standby when the location specified by the `StandbyArchiveLocation` fails. The property has an instance scope, and the location it specifies has to be accessible by the instance.

Category | Description
--- | ---
Datatype | String
Valid values | Directory specification on system where the standby instance is located
Broker default | Empty string
Imported? | No
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical or logical
Corresponds to ... | On the standby instance, the `LOCATION` attribute for the `LOG_ARCHIVE_DEST_``n` initialization parameter that represents an alternate destination of the local destination that matches the property `StandbyArchiveLocation` On the primary database, the `TEMPLATE` attribute for the `LOG_ARCHIVE_DEST_``n` initialization parameter that represents an alternate destination
Scope | Instance
Enterprise Manager name | `Alternate Standby Location`

Footnote 1 Although this property is set for the standby instance, it is indirectly related to redo transport services for the primary database. The broker sets up both an alternate local destination on the standby instance and an alternate remote destination on the primary database.

Note: On a logical standby database, Oracle recommends the `LOCATION` attribute of the `LOG_ARCHIVE_DEST_``n` initialization parameter for the local destination be different from the value of `AlternateLocation` property.

### 9.2.2 ApplyInstanceTimeout

Specifies the number of seconds the broker waits after detecting the current apply instance failed and before initiating the apply instance failover.

Category | Description
--- | ---
Datatype | Integer
Valid values | `>=0` (seconds)
Broker default | `0` (results in immediate apply instance failover)
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Physical or logical
Corresponds to ... | Not applicable
Scope | Database
Enterprise Manager name | Not applicable

### 9.2.3 ApplyParallel

Specifies whether Redo Apply should use multiple processes to apply redo data to the physical standby database. If Redo Apply is offline, then setting the property has no immediate effect. However, when Redo Apply is online again, the value of the property is used to determine the parallel apply behavior of Redo Apply.

Category | Description
--- | ---
Datatype | String
Valid values | `AUTO`—the number of parallel processes used for Redo Apply is automatically determined by Oracle based on the number of CPUs that the system has. `NO`—no parallel apply.
Broker default | `AUTO`
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Physical
Corresponds to ... | `AUTO` corresponds to the `PARALLEL` clause of the `ALTER DATABASE RECOVER MANAGED STANDBY DATABASE` statement `NO` corresponds to the `NOPARALLEL` clause of the `ALTER DATABASE RECOVER MANAGED STANDBY DATABASE` statement
Scope | Database
Enterprise Manager name | Not applicable

### 9.2.4 ArchiveLagTarget

Limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the amount of time you specify (in seconds) elapses. That way, the standby database will not miss redo records generated from a time range longer than the value set for the `ARCHIVE_LAG_TARGET` initialization parameter.

Category | Description
--- | ---
Datatype | Number
Valid values | Seconds (either 0 seconds, or any number from 60 to 7200 seconds)
Broker default | 0 (disabled)
Imported? | Yes, from the `ARCHIVE_LAG_TARGET` initialization parameter
Parameter class | Dynamic
Role | Primary
Standby type | Not applicable
Corresponds to ... | `ARCHIVE_LAG_TARGET=``seconds` initialization parameter
Scope | Database
Enterprise Manager name | `Archive Lag Target`

### 9.2.5 Binding

``Specifies whether or not the standby destination is `MANDATORY` or `OPTIONAL`.

Category | Description
--- | ---
Datatype | String
Valid values | `MANDATORY` You can specify a policy for reuse of online redo log files using the `MANDATORY` value. If the archiving operation of a mandatory destination fails, online redo log files cannot be overwritten. `OPTIONAL` You can specify a policy for reuse of online redo log files using the `OPTIONAL` value. If the archiving operation of an optional destination fails, the online redo log files are overwritten.
Broker default | `OPTIONAL`
Imported? | Yes, from the `BINDING` column of the `V$ARCHIVE_DEST` view of the primary database
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical and logical
Corresponds to ... | `MANDATORY` and `OPTIONAL` attributes for the `LOG_ARCHIVE_DEST_``n` initialization parameter of the primary database `BINDING` column of the `V$ARCHIVE_DEST` view of the primary database
Scope | Database
Enterprise Manager name | Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_``n` value of the primary database.

### 9.2.6 DbFileNameConvert

D``istinguishes standby datafile filenames from primary datafile filenames. You must set this property on all standby databases. If you add a datafile to the primary database, this property converts the datafile name on the primary database to the datafile on the standby database.

This property is used in the following situations:

- At standby mount time, it is used to rename primary datafile filenames to standby datafile filenames if the datafile file path on the standby system is different from the primary database system.

- When a new data file is created on the primary database, a corresponding new data file will be created on the standby database if the `StandbyFileManagement` property is set to `'AUTO'`. Oracle uses the data-file file-path mapping information from the `DbFileNameConvert` property to determine the standby file path of the new standby data file. If the `StandbyFileManagement` property is set to `'MANUAL'`, you must add a corresponding file to the standby database.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | Set the value of this property to a list of string pairs: The first string is the substring found in the datafile names on the primary database. The second string is the substring found in the datafile names on the standby database. For example, `('string1', 'string2', 'string3', 'string4',...)` Where: `string1` is the substring of the primary database filename. `string2` is the substring of the standby database filename. `string3` is the substring of the primary database filename. `string4` is the substring of the standby database filename.
  Broker default | ' '
  Imported? | Yes, from the `DB_FILE_NAME_CONVERT` initialization parameter
  Parameter class | Static
  Role | Standby
  Standby type | Physical
  Corresponds to ... | `DB_FILE_NAME_CONVERT` initialization parameter
  Scope | Database
  Enterprise Manager name | `DB File Name Convert`

### 9.2.7 DelayMins

S``pecifies the number of minutes log apply services will delay applying the archived redo log files on the standby database. When the `DelayMins` property is set to the default value of 0 minutes, log apply services apply redo data as soon as it is received, using real-time apply if the standby database is configured with standby redo logs.

If the `DelayMins` property is set to 0 and standby redo logs are configured on the standby database, start log apply services as follows:

- Start Redo Apply on physical standby databases using the following SQL statement:

      ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

- Start SQL Apply on logical standby databases using the following SQL statement:

      ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

If the `DelayMins` property is set to 0 but standby redo logs are not configured on the standby database, start log apply services as follows:

- Start Redo Apply on physical standby databases using the following SQL statement:

      ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

- Start SQL Apply on logical standby databases using the following SQL statement:

      ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0 (minutes)
Broker default | `0`
Imported? | Yes, from the `DELAY_MINS` column of the `V$ARCHIVE_DEST` view of the primary database
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical and logical
Corresponds to ... | `DELAY` attribute for the `LOG_ARCHIVE_DEST_``n` initialization parameter of the primary database `DELAY_MINS` column of the `V$ARCHIVE_DEST` view of the primary database Options used to start Redo Apply and SQL Apply
Scope | Database
Enterprise Manager name | `Apply Delay (mins)`

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_``n` value of the primary database.

### 9.2.8 Dependency

``Specifies the database unique (`DB_UNIQUE_NAME`) name (can be the primary or a standby database name) on which this database depends for receiving archived redo log files.

Category | Description
--- | ---
Datatype | String
Valid values | Database unique name (`DB_UNIQUE_NAME`), except for the standby database itself, or you can set this property to an empty string.
Broker default | ' '
Imported? | No
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical or logical
Corresponds to ... | `DEPENDENCY` attribute for the `LOG_ARCHIVE_DEST_`n initialization parameter of the primary database
Scope | Database
Enterprise Manager name | Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_`n value of the primary database.

See Also: Oracle Data Guard Concepts and Administration

### 9.2.9 FastStartFailoverTarget

Specifies the `DB_UNIQUE_NAME` of the database that will be the target of a fast-start failover when this database is the primary database. See Step 2 in Section 5.5.2 for more information about setting this property.

Category | Description
--- | ---
Datatype | String
Valid Values | `DB_UNIQUE_NAME` of the database that is the target of the fast-start failover.
Broker default | If only one standby database exists, then the broker selects that as the default value for this property on the primary database when fast-start failover is enabled. If more than one standby database exists, you must specify the `FastStartFailoverTarget` value explicitly, prior to enabling fast-start failover. For the target standby database, the broker automatically selects the current primary database as the value for this property when fast-start failover is enabled.
Imported | No
Parameter class | Not applicable
Role | Primary or standby
Standby type | Physcial or logical
Corresponds to ... | Not applicable
Scope | Database
Enterprise Manager name | Enterprise Manager displays the value for the current primary database on the Data Guard Overview page, along with whether or not fast-start failover has been enabled.

### 9.2.10 FastStartFailoverThreshold

Defines the number of seconds the observer attempts to reconnect to the primary database before initiating a fast-start failover to the target standby database. The time interval starts when the observer first detects conditions for triggering a fast-start failover (described in Section 5.5.6). If the observer is unable to regain a connection to the primary database within the specified time, then the observer begins a fast-start failover. See Step 3 in Section 5.5.2 for more information about setting this property.

Category | Description
--- | ---
Datatype | Integer
Valid Value | Integral number of seconds. Must be greater than zero.
Broker default | 30 seconds
Imported | No
Parameter class | Not applicable
Role | Target standby database that is about to fail over to the primary role
Standby type | Physical or logical
Corresponds to ... | Not applicable
Scope | Broker configuration. This value will be consumed by the observer after fast-start failover has been enabledFoot 1
Enterprise Manager name | Oracle Enterprise Manager presents this as "Fast-Start Failover Threshold" on the Data Guard Overview page.

Footnote 1 If you specify `FastStartFailoverThreshold` when fast-start failover is enabled, the observer will recognize the new value the next time it contacts the primary database.

### 9.2.11 HostName

Specifies the name of the host on which the instance is running. The property can only be updated when broker management of the database is disabled. You should only update the value when the host is renamed, in which case you need to disable broker management of the database, update the `HostName` property to match with the new host name, and then reenable broker management of the database.

Note: If the value of the `HostName` property does not match the actual name of the host, broker management of the database cannot be enabled.

Category | Description
--- | ---
Datatype | String
Valid values | Name of the host on which the instance is running
Broker default | Not applicable
Imported? | Yes
Parameter class | Not applicable
Role | Primary and standby
Standby type | Physical or logical
Corresponds to ... | `HOST_NAME` column of the `V$INSTANCE` view
Scope | Instance
Enterprise Manager name | Not applicable

### 9.2.12 InitialConnectIdentifier

Specifies the initial connection identifier the broker uses to make the first connection to a database. If using DGMGRL, you supply the value when you enter the `CREATE CONFIGURATION` or `ADD DATABASE` command. If using Enterprise Manager, the value is supplied automatically. You should only update the value of this property when the original value has an error.

Category | Description
--- | ---
Datatype | String
Valid values | A connect identifier that can be used to connect to this database
Broker default | Not applicable
Imported? | No
Parameter class | Not applicable
Role | Primary and standby
Standby type | Physical or logical
Corresponds to ... | Not applicable
Scope | Database
Enterprise Manager name | Not applicable

### 9.2.13 Local ListenerAddress

Specifies the listener address at which the instance is registered. The property can only be updated when broker management of the database is disabled. You should only update the value when the `LOCAL_LISTENER` initialization parameter value is being changed, in which case you need to:

1. Disable broker management of the database

2. Update the `LOCAL_LISTENER` initialization parameter value

3. Update the `LocalListenerAddress` property in listener `ADDRESS` format to match with the new `LOCAL_LISTENER` address

4. Reenable broker management of the database

In the event that the `LOCAL_LISTENER` initialization parameter value of instances belonging to more than one database is being changed, it is recommended to:

1. Disable the configuration

2. Make the `LOCAL_LISTENER` initialization parameter value changes at all of the instances

3. Make the `LocalListenerAddress` property changes for all of the affected instances

4. Enable the configuration

Note: If the value of the `LocalListenerAddress` property does not match the actual address of the listener at which the instance is registered, broker management of the database cannot be enabled.

Category | Description
--- | ---
Datatype | String
Valid values | Listener address, in `ADDRESS` format
Broker default | Same as the default value for the `LOCAL_LISTENER` address initialization parameter.
Imported? | Yes, from the `LOCAL_LISTENER` initialization parameter and translated into `ADDRESS` format if the initialization parameter value is a new service name
Parameter class | Dynamic
Role | Primary and standby
Standby type | Physical or logical
Corresponds to ... | `LOCAL_LISTENER` initialization parameter
Scope | Instance
Enterprise Manager name | Not applicable

### 9.2.14 Log ArchiveFormat

S``pecifies the format for filenames of archived redo log files using a database ID (`%d`), thread (`%t`), sequence number (`%s`), and resetlogs ID (`%r`).

Category | Description
--- | ---
Datatype | String
Valid values | `%d_%t_%s_%r`
Broker default | Empty string
Imported? | Yes, from the `LOG_ARCHIVE_FORMAT` initialization parameter on the primary database
Parameter class | Static
Role | Primary and standby
Standby type | Physical and logical
Corresponds to ... | `LOG_ARCHIVE_FORMAT` initialization parameter
Scope | Instance
Enterprise Manager name | Not applicable

### 9.2.15 LogArchiveMaxProcesses

S``pecifies the initial number of archiver processes (ARCn) the Oracle database invokes. The actual number of archiver processes in use may increase subsequently based on the archiving workload.

Category | Description
--- | ---
Datatype | Integer
Valid values | 1 to 30
Broker default | `2`
Imported? | Yes, from the `LOG_ARCHIVE_MAX_PROCESSES` initialization parameter
Parameter class | Dynamic
Role | Primary and standby
Standby type | Physical and logical
Corresponds to ... | `LOG_ARCHIVE_MAX_PROCESSES` initialization parameter
Scope | Database
Enterprise Manager name | `Archiver Processes`

### 9.2.16 LogArchiveMinSucceedDest

Controls when online redo log files are available for reuse. For the online redo log files to be available for reuse, archiving must succeed to a minimum number of destinations.

Category | Description
--- | ---
Datatype | Integer
Valid values | 1 to 10
Broker default | 1
Imported? | Yes, from the `LOG_ARCHIVE_MIN_SUCCEED_DEST` initialization parameter
Parameter class | Dynamic
Role | Primary
Standby type | Not applicable
Corresponds to ... | `LOG_ARCHIVE_MIN_SUCCEED_DEST` initialization parameter
Scope | Database
Enterprise Manager name | Not applicable

### 9.2.17 LogArchiveTrace

S``et this property to an integer value to see the progression of the archiving of online redo log files on the primary and the standby databases. The Oracle database writes an audit trail of the archived redo log files received from the primary database into process trace files.

Category | Description
--- | ---
Datatype | Integer
Valid values | A valid value is the sum of any combination of any of the following values: 0: Disable archive redo log tracing 1: Track archiving of online redo log file 2: Track archiving status of each archive redo log destination 4: Track archiving operational phase 8: Track `ARCHIVELOG` destination activity 16: Track detailed `ARCHIVELOG` destination activity 32: Track `ARCHIVELOG` destination parameter modifications 64: Track ARC`n` process state activity 128: Track FAL (fetch archive log) server related activities 256: Tracks RFS Logical Client 512: Tracks LGWR redo shipping network activity 1024: Tracks RFS physical client 2048: Tracks RFS/ARCn ping heartbeat 4096: Tracks real-time apply activity 8192: Tracks Redo Apply (media recovery or physical standby)
Broker default | 255
Imported? | Yes, from the `LOG_ARCHIVE_TRACE` initialization parameter
Parameter class | Dynamic
Role | Primary and standby
Standby type | Physical and logical
Corresponds to... | `LOG_ARCHIVE_TRACE` initialization parameter
Scope | Instance
Enterprise Manager name | `Log Archive Trace`

### 9.2.18 LogFileNameConvert

C``onverts the filename of an online redo log file on the primary database to the filename of a corresponding online redo log file on the standby database.

Category | Description
--- | ---
Datatype | String
Valid values | Set the value of this property to a list of an even number of string pairs, separated by commas. The first string is the substring found in the datafile names on the primary database. The second string is the substring found in the datafile names on the standby database. For example, `('string1', 'string2', 'string3', 'string4',...)` Where: `string1` is the substring of the primary database filename. `string2` is the substring of the standby database filename. `string3` is the substring of the primary database filename. `string4` is the substring of the standby database filename.
Broker default | ' '
Imported? | Yes, from the `LOG_FILE_NAME_CONVERT` initialization parameter
Parameter class | Static
Role | Standby
Standby type | Physical
Corresponds to ... | `LOG_FILE_NAME_CONVERT` initialization parameter
Scope | Database
Enterprise Manager name | `Log File Name Convert`

### 9.2.19 LogShipping

``Specifies whether or not redo transport services can send archived redo log files to the particular standby database. The broker uses the value of the `LogShipping` property only when the primary database is in the `ONLINE` state:

- If the primary database is in the `LOG-TRANSPORT-OFF` state, then redo transport services are offline to all standby databases, regardless of whether or not the `LogShipping` property is set to `ON` or `OFF`.

- If the primary database is in the `ONLINE` state and the value of the `LogShipping` property is `ON`, then redo transport services are enabled to send archived redo log files to the particular standby database. If the `LogShipping` property is `OFF`, then redo transport services are disabled to send archived redo log files to the particular standby database.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | `ON` or `OFF`
  Broker default | `ON`
  Imported? | No
  Parameter class | Dynamic
  Role | StandbyFoot 1
  Standby type | Physical and logical
  Corresponds to ... | `ENABLE` and `DEFER` values for the `LOG_ARCHIVE_DEST_STATE_`n initialization parameter of the primary database
  Scope | Database
  Enterprise Manager name | `Log Shipping`

  Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_`n value of the primary database.

### 9.2.20 L ogXptMode

Enable s you to set the redo transport service. You set the redo transport services on each standby database to one of the following modes:

- `SYNC`

  Configures redo transport services for this standby database using the `LGWR`, `SYNC`, and `AFFIRM` attributes of the `LOG_ARCHIVE_DEST_``n` initialization parameter. Standby redo log files are required. This mode is required for the maximum protection or maximum availability data protection modes. This redo transport service enables the highest grade of data protection to the primary database, but also incurs the highest performance impact.

- `ASYNC`

  Configures redo transport services for this standby database using the `LGWR`, `ASYNC`, and `NOAFFIRM` attributes of the `LOG_ARCHIVE_DEST_``n` initialization parameter. Standby redo log files are required. This mode enables a moderate grade of data protection to the primary database, and incurs a lower performance impact than `SYNC`.

- `ARCH`

  Configures redo transport services for this standby database using the `ARCH` attribute of the `LOG_ARCHIVE_DEST_``n` initialization parameter. Standby redo log files are not required. This mode enables the lowest grade of data protection to the primary database, and incurs the lowest performance impact. This is the default setting.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | `SYNC` or `ASYNC` or `ARCH`
  Broker default | `ASYNC` for standby databases with standby redo log files `ARCH` for standby databases without standby redo log files
  Imported? | Yes, from the `ARCHIVER`, `TRANSMIT_MODE`, and `AFFIRM` columns of `V$ARCHIVE_DEST` view of the primary database
  Parameter class | Dynamic
  Role | StandbyFoot 1
  Standby type | Physical or logical
  Corresponds to ... | `ARCH`, `LGWR`, `SYNC`, `ASYNC`, `AFFIRM`, and `NOAFFIRM` attributes for the `LOG_ARCHIVE_DEST_``n` initialization parameter of the primary database `ARCHIVER`, `TRANSMIT_MODE`, and `AFFIRM` columns of `V$ARCHIVE_DEST` view of the primary database
  Scope | Database
  Enterprise Manager name | `Redo Transport Service`

  Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_``n` value of the primary database.

  See Also: Chapter 4 for more information about setting data protection modes for redo transport services

### 9.2.21 LsbyASkipCfgPr

Provides a way to add a skip specification to SQL Apply to control the apply service to skip (ignore) SQL statements that you do not want to apply to the logical standby database. The `SKIP` operation:

- Sets the criteria for identifying the SQL statements that will not be applied to the standby database

- Specifies any additional processing that will be done, if necessary

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category | Description
--- | ---
Datatype | String
Valid values | A valid set of arguments to the `DBMS_LOGSTDBY.SKIP` procedure
Broker default | Empty string
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.SKIP` procedure
Scope | Database
Enterprise Manager name | `Add Skip Table Entries`

See Also: Oracle Database PL/SQL Packages and Types Reference

### 9.2.22 LsbyASkipErrorCfgPr

Adds a skip error specification to SQL Apply. It provides criteria to determine if an error should cause SQL Apply to stop. All errors to be skipped are stored in system tables that describe how exceptions should be handled.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category | Description
--- | ---
Datatype | String
Valid values | A valid set of arguments to the `DBMS_LOGSTDBY.SKIP_ERROR` procedure. The string must contain comma separators between the arguments.
Broker default | Empty string
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.SKIP_ERROR` procedure
Scope | Database
Enterprise Manager name | `Add Skip Table Entries`

See Also: Oracle Database PL/SQL Packages and Types Reference

### 9.2.23 LsbyASkipTxnCfgPr

Skips over a transaction that caused SQL Apply to stop applying transactions to the logical standby database. This property enables you to specify the transaction ID (`XIDSQN NUMBER`) of the problematic transaction that you want SQL Apply to ignore. Before you restart SQL Apply, you should issue a SQL transaction that will correctly update the logical standby database in place of the skipped transaction. Applying a compensating transaction will help keep the logical standby database transactionally consistent with the primary database.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category | Description
--- | ---
Datatype | String
Valid values | A valid set of arguments to the `DBMS_LOGSTDBY.SKIP_TRANSACTION` procedure. Use comma separators between the arguments.
Broker default | Empty string
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.SKIP_TRANSACTION` procedure
Scope | Database
Enterprise Manager name | `Skip Edit Properties`

Note: Enterprise Manager indirectly supports skipping a transaction using the Skip Edit Properties page.

See Also: Oracle Database PL/SQL Packages and Types Reference

### 9.2.24 LsbyDSkipCfgPr

Deletes an existing skip specification from SQL Apply. It reverses or removes the actions of the LsbyASkipCfgPr property by finding the record, matching all the parameters, and removing the record from the system table. The match must be exact, and multiple skip actions can be removed only by a matching number of unskip actions. You cannot remove multiple skip actions by using wildcard characters as a value to this property.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category | Description
--- | ---
Datatype | String
Valid Values | A valid set of arguments to the `DBMS_LOGSTDBY.UNSKIP` procedure
Broker Default | Empty string
Imported? | No
Parameter Class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.UNSKIP` procedure
Scope | Database
Enterprise Manager name | `Remove Skip Table Entries`

See Also: Oracle Database PL/SQL Packages and Types Reference

### 9.2.25 LsbyDSkipErrorCfgPr

Deletes an existing skip error specification from SQL Apply. It reverses or removes the actions of the LsbyASkipErrorCfgPr property by finding the record, matching all of the parameters and removing the record from the system table. The match must be exact, and multiple skip actions can be removed only by a matching number of unskip actions. You cannot remove multiple skip actions by using wildcard characters as a value to this property.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category | Description
--- | ---
Datatype | String
Valid values | A valid set of arguments to the `DBMS_LOGSTDBY.UNSKIP_ERROR` procedure. The string must contain comma separators between the arguments.
Broker default | Empty string
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.UNSKIP_ERROR` procedure
Scope | Database
Enterprise Manager name | `Remove Skip Table Entries`

See Also: Oracle Database PL/SQL Packages and Types Reference

### 9.2.26 LsbyDSkipTxnCfgPr

Reverses or removes the actions of the LsbyASkipTxnCfgPr property. The transaction IDs must match exactly, and multiple skip transaction actions can be removed only by a matching number of unskip transaction actions. You cannot remove multiple skip transaction actions by using wildcard characters as a value to this property.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category | Description
--- | ---
Datatype | String
Valid values | A valid set of arguments to the `DBMS_LOGSTDBY.UNSKIP_TRANSACTION` procedure
Broker default | Empty string
Imported? | No
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.UNSKIP_TRANSACTION` procedure
Scope | Database
Enterprise Manager name | Not applicable

See Also: Oracle Database PL/SQL Packages and Types Reference

### 9.2.27 Lsby MaxEventsRecorded

Specifies the number of events that will be stored in the `DBA_LOGSTDBY_EVENTS` table, which stores logical standby event information.

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0
Broker default | 0
Imported? | Yes, from the `MAX_EVENTS_RECORDED` row of `SYSTEM.LOGSTDBY$PARAMETERS`
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED')` and the `DBMS_LOGSTDBY.APPLY_UNSET('MAX_EVENTS_RECORDED')` procedures
Scope | Database
Enterprise Manager name | `Max Events Recorded`

### 9.2.28 LsbyMaxSga

Specifies the number of megabytes for the allocation of SQL Apply cache in the system global area (SGA). If the value is 0, SQL Apply uses one quarter of the value set for the `SHARED_POOL_SIZE` initialization parameter.

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0
Broker default | 0
Imported? | Yes, from the `MAX_SGA` row of `SYSTEM.LOGSTDBY$PARAMETERS`
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.APPLY_SET('MAX_SGA')` and the `DBMS_LOGSTDBY.APPLY_UNSET('MAX_SGA')` procedures
Scope | Instance
Enterprise Manager name | `Max SGA (MB)`

### 9.2.29 Lsby MaxServers

Specifies the number of parallel query servers specifically reserved for SQL Apply. If the value is 0, SQL Apply uses all available parallel query servers to read the log files and apply changes.

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0
Broker default | 0
Imported? | Yes, from the `MAX_SERVERS` row of `SYSTEM.LOGSTDBY$PARAMETERS`
Parameter class | Not applicable
Role | Standby
Standby type | Logical
Corresponds to ... | `DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS')` and the `DBMS_LOGSTDBY.APPLY_UNSET('MAX_SERVERS')` procedures
Scope | Instance
Enterprise Manager name | `Max Servers`

### 9.2.30 Lsby RecordAppliedDdl

Controls whether or not DDL statements that were applied to the logical standby database are recorded in the `DBA_LOGSTDBY_EVENTS` table. Specify one of the following values:

- `TRUE`: DDL statements applied to the logical standby database are recorded in the `DBA_LOGSTDBY_EVENTS` table. This is the default setting.

- `FALSE`: Applied DDL statements are not recorded.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | `TRUE` or `FALSE`
  Broker default | `TRUE`
  Imported? | Yes, from the `RECORD_APPLIED_DDL` row of `SYSTEM.LOGSTDBY$PARAMETERS`
  Parameter class | Not applicable
  Role | Standby
  Standby type | Logical
  Corresponds to ... | `DBMS_LOGSTDBY.APPLY_SET('RECORD_APPLIED_DDL')` and the `DBMS_LOGSTDBY.APPLY_UNSET('RECORD_APPLIED_DDL')` procedures
  Scope | Database
  Enterprise Manager name | `Record Applied DDL`

### 9.2.31 Lsby RecordSkipDdl

Controls whether or not skipped DDL statements are recorded in the `DBA_LOGSTDBY_EVENTS` table. Specify one of the following values:

- `TRUE`: Skipped DDL statements are recorded in the `DBA_LOGSTDBY_EVENTS` table. This is the default setting.

- `FALSE`: Skipped DDL statements are not recorded in the `DBA_LOGSTDBY_EVENTS` table.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | `TRUE` or `FALSE`
  Broker default | `TRUE`
  Imported? | Yes, from the `RECORD_SKIP_DDL` row of `SYSTEM.LOGSTDBY$PARAMETERS`
  Parameter class | Not applicable
  Role | Standby
  Standby type | Logical
  Corresponds to ... | `DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_DDL')` and the `DBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_DDL')` procedures
  Scope | Database
  Enterprise Manager name | `Record Skip DDL`

### 9.2.32 LsbyRecordSkipErrors

Controls whether or not skipped errors (as described by the `DBMS_LOGSTDBY.SKIP_ERROR` procedure) are recorded in the `DBA_LOGSTDBY_EVENTS` table. Specify one of the following values:

- `TRUE`: Skipped errors are recorded in the `DBA_LOGSTDBY_EVENTS` table.

- `FALSE`: Skipped errors are not recorded in the `DBA_LOGSTDBY_EVENTS` table.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | `TRUE` or `FALSE`
  Broker default | `TRUE`
  Imported? | Yes, from the `RECORD_SKIP_ERRORS` row of `SYSTEM.LOGSTDBY$PARAMETERS`
  Parameter class | Not applicable
  Role | Standby
  Standby type | Logical
  Corresponds to | `DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_ERRORS')` and the `DBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_ERRORS')` procedures
  Scope | Database
  Enterprise Manager name | `Record Skip Errors`

### 9.2.33 Lsby TxnConsistency

Controls the level of transaction consistency maintained between the primary and standby databases. Specify one of the following values:

- `FULL`: Transactions are applied to the logical standby database in the exact order in which they were committed on the primary database. This option may affect performance.

- `READ_ONLY`: Transactions are committed out of order (which provides better performance). SQL `SELECT` statements return read-consistent results. This is particularly beneficial when the logical standby database is being used to generate reports.

  Note: DML statements involving standby tables are not allowed in this mode.

- `NONE`: Transactions are committed out of order and no attempt is made to provide read-consistent results. This results in the best performance of the three modes. If applications reading the logical standby database make no assumptions about transaction order, this option works well.

  Category | Description
  --- | ---
  Datatype | String
  Valid values | `FULL` or `READ_ONLY` or `NONE`
  Broker default | `FULL`
  Imported? | Yes, from the `PRESERVE_COMMIT_ORDER` row of `SYSTEM.LOGSTDBY$PARAMETERS`
  Parameter class | Not applicable
  Role | Standby
  Standby type | Logical
  Corresponds to ... | `DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER')` and the `DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER')` procedures
  Scope | Database
  Enterprise Manager name | `Transaction Consistency Level`

### 9.2.34 Max Connections

Specifies how the archiver (ARCn) processes on the primary database coordinate when sending redo data to standby databases. If the `MaxConnections` property is set to a nonzero value, redo transport services use multiple network connections to transmit redo data using the archiver process (ARCn).

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0
Broker default | 0
Imported? | Yes, from the MAX_CONNECTIONS column of the `V$ARCHIVE_DEST` view for the primary database.
Parameter class | Dynamic
Role | Standby
Standby type | Physical and logical
Corresponds to ... | `LOG_ARCHIVE_MAX_PROCESSES` and `PARALLEL_MAX_SERVERS` initialization parametersFoot 1 `MAX_CONNECTIONS` attribute for the `LOG_ARCHIVE_DEST_``n` initialization parameter of the primary database `MAX_CONNECTIONS` column of the `V$ARCHIVE_DEST` view of the primary database

Footnote 1 The `LOG_ARCHIVE_MAX_PROCESSES` and `PARALLEL_MAX_SERVERS` initialization parameters affect the actual number of ARCn processes used by an instance. See Oracle Data Guard Concepts and Administration for more information.

### 9.2.35 Max Failure

Specifies the maximum number of contiguous archiving failures before the redo transport services stop trying to transport archived redo log files to the standby database. A value of zero indicates that an unlimited number of failures are allowed.

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0
Broker default | `0`
Imported? | Yes, from the `MAX_FAILURE` column of `V$ARCHIVE_DEST` view of the primary database
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical and logical
Corresponds to ... | `MAX_FAILURE` attribute for the `LOG_ARCHIVE_DEST_`n initialization parameter of the primary database `MAX_FAILURE` column of the `V$ARCHIVE_DEST` view of the primary database
Scope | Database
Enterprise Manager name | Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_`n value of the primary database.

### 9.2.36 NetTimeout

Specifies the number of seconds the LGWR waits for Oracle Net Services to respond to a LGWR request. It is used to bypass the long connection timeout in TCP. This property is only used when the `LogXptMode` property of the same database is set to `SYNC` or `ASYNC`.

Category | Description
--- | ---
Datatype | Integer
Valid values | 0, 15 to 1200
Broker default | 180
Imported? | Yes, from the `NET_TIMEOUT` column of `V$ARCHIVE_DEST` view of the primary database
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical and logical
Corresponds to ... | `NET_TIMEOUT` attribute of the `LOG_ARCHIVE_DEST_``n` initialization parameter of the primary database `NET_TIMEOUT` column of `V$ARCHIVE_DEST` view of the primary database
Scope | Database
Enterprise Manager name | Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_``n` value of the primary database.

### 9.2.37 PreferredApplyInstance

Indicates that a particular instance is the preferred choice for serving log apply services. It is only used when the database is a standby RAC database. The value could be an empty string (default) which means the broker chooses the apply instance.

Category | Description
--- | ---
Datatype | String
Valid Values | The instance name (SID) or empty string
Broker Default | Empty string
Imported? | No
Parameter Class | Not applicable
Role | Standby
Standby Type | Physical and logical
Corresponds to | Not applicable
Scope | Database
Enterprise Manager name | `Apply Instance`

See Also: Section 4.5.7 for more information

### 9.2.38 ReopenSecs

Specifies the minimum number of seconds before the archiver process (ARCn, foreground, or log writer process) should try again to access a previously failed destination.

Category | Description
--- | ---
Datatype | Integer
Valid values | >=0 seconds
Broker default | `300`
Imported? | Yes, from the `REOPEN_SECS` column of `V$ARCHIVE_DEST` view of the primary database
Parameter class | Dynamic
Role | StandbyFoot 1
Standby type | Physical and logical
Corresponds to ... | `REOPEN` attribute for the `LOG_ARCHIVE_DEST_``n` initialization parameter of the primary database `REOPEN_SECS` column of the `V$ARCHIVE_DEST` view of the primary database
Scope | Database
Enterprise Manager name | Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the `LOG_ARCHIVE_DEST_``n` value of the primary database.

### 9.2.39 SidName

Specifies the SID of the instance. The property can only be updated when broker management of the database is disabled. You should only update the value when the SID is changed, in which case you need to disable broker management of the database, update the `SidName` property to match with the new SID, and reenable broker management of the database.

Note: If the value of the `SidName` property does not match the actual value of the SID, broker management of the database cannot be enabled.

Category | Description
--- | ---
Datatype | String
Valid values | SID of the instance
Broker default | Not applicable
Imported? | Yes
Parameter class | Not applicable
Role | Primary and standby
Standby type | Physical or logical
Corresponds to ... | `INSTANCE_NAME` column of the `V$INSTANCE` view
Scope | Instance
Enterprise Manager name | Not applicable

### 9.2.40 StandbyArchiveLocation

Specifies the location of archived redo log files arriving from a primary database. Oracle recommends that you always explicitly set the value (if flash recovery area is not in use).

Category | Description
--- | ---
Datatype | String
Valid values | Nonempty file specification of the location of archived redo log files on the standby database
Broker default | `dgsby_`db_unique_name
Imported? | Yes, from the `DESTINATION` column of the `V$ARCHIVE_DEST` fixed view of the standby database where the destination is a local destination and where the `VALID_FOR` attribute is compatible with the string `(STANDBY_ROLE, STANDBY_LOGFILE)`; if no such destination exists, import is from the `STANDBY_ARCHIVE_DEST` initialization parameter
Parameter class | Dynamic
Role | Standby
Standby type | Physical or logical
Corresponds to ... | `LOCATION` attribute of the `LOG_ARCHIVE_DEST_`n initialization parameter of the standby database with `VALID_FOR` compatible with `(STANDBY_ROLE, STANDBY_LOGFILE)` `DESTINATION` column of the `V$ARCHIVE_DEST` view of the standby database
Scope | Instance
Enterprise Manager name | `Standby Archive Location`

Note: On a logical standby database, Oracle recommends the `LOCATION` attribute of the `LOG_ARCHIVE_DEST_`n initialization parameter for the local destination be different from the value of `StandbyArchiveLocation` property.

### 9.2.41 StandbyFileManagement

Affects how the add datafile operation on the primary database is applied on the standby database. If this property is set to `AUTO`, in conjunction with valid settings in the `DbFileNameConvert` property, a corresponding new datafile is automatically created on the standby database. The location of this new standby datafile is determined by the value of the `DbFileNameConvert` property.

If this property is set to `MANUAL`, you have to create the correct new datafile on the standby database manually.

Category | Description
--- | ---
Datatype | String
Valid values | `AUTO` or `MANUAL`
Broker default | `AUTO`
Imported? | Yes, from the `STANDBY_FILE_MANAGEMENT` initialization parameter
Parameter class | Dynamic
Role | Standby
Standby type | Physical or logical
Corresponds to ... | `STANDBY_FILE_MANAGEMENT` initialization parameter
Scope | Database
Enterprise Manager name | Not applicable